home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 8966 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.2 KB
  1. Path: mail2news.demon.co.uk!genesis.demon.co.uk
  2. From: Lawrence Kirby <fred@genesis.demon.co.uk>
  3. Newsgroups: comp.unix.programmer,comp.lang.c
  4. Subject: Re: Runtime ANSI C checking tool?
  5. Date: Thu, 07 Mar 96 17:28:17 GMT
  6. Organization: none
  7. Message-ID: <826219697snz@genesis.demon.co.uk>
  8. References: <DnI89B.EnH@pgh.nauticom.net> <p5ag239ede.fsf@lemming.wellfleet.com>
  9. Reply-To: fred@genesis.demon.co.uk
  10. X-NNTP-Posting-Host: genesis.demon.co.uk
  11. X-Newsreader: Demon Internet Simple News v1.27
  12. X-Mail2News-Path: genesis.demon.co.uk
  13.  
  14. In article <p5ag239ede.fsf@lemming.wellfleet.com>
  15.            psmith@wellfleet.com "Paul D. Smith" writes:
  16.  
  17. >%% Regarding Runtime ANSI C checking tool?;
  18. >%% tybergm@pgh.nauticom.net (Mark E. Tyberg) writes:
  19. >
  20. >    met> Does anyone know of a program (for UNIX) that can do _runtime_
  21. >    met> checking for ANSI C violations/undefined behavior?
  22. >
  23. >Well, a well-written ANSI C compiler should handle all language
  24. >violations, and a well-written ANSI C system library should catch all
  25. >runtime violations (passing NULL to strcpy() or something, for
  26. >example).
  27.  
  28. Not possible in general (at least for the compiler or the standard library)
  29. e.g.
  30.  
  31. int foo(int *p, int *q)
  32. {
  33.     return ++*p + ++*q;
  34. }
  35.  
  36. This results in undefined behaviour if the same value is passed for p and
  37. q.
  38.  
  39. >Some vendors try to be cute and allow you to pass invalid args to
  40. >standard functions without complaint by catching them and ignoring them
  41. >(SunOS in particular does this a lot--not that SunOS's libc is ANSI by
  42. >any stretch of the imagination :), but I say they should catch them and
  43. >call abort() immediately!  They're not doing you any favors by making it
  44. >that much more difficult to find your bug.  Dump core up front!  Make it
  45. >easy to find the problem!
  46.  
  47. You can catch null pointers by making sure that address 0 is mapped out
  48. of your address space - that isn't a job for the standard library. I agree
  49. that it is better not to have any error checking than error checking that
  50. simply causes the error condition to be passed over.
  51.  
  52. -- 
  53. -----------------------------------------
  54. Lawrence Kirby | fred@genesis.demon.co.uk
  55. Wilts, England | 70734.126@compuserve.com
  56. -----------------------------------------
  57.